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Title: DRIVER-SPECIFIC CONTEXT FOR KERNEL-MODE 

SHIMMING 

5 TECHNICAL FIELD 

The present invention relates generally to computers and more particularly toward 
a system and method of shimming kemel-mode drivers. 

BACKGROUND 

1 0 Shimming is a technique that allows additional functionality to be inserted 

between an application programming interface (API) client (e.g., an application, driver) 
and an API service (e,g., suppUed by an operating system). An API client application 
may be written to use a collection of externally provided services (APIs), which provide 
some well-described functionality. These API services reside external to the client 

15 program, for example, contained in a dynamically linked library (DLL). 

One of the major benefits provided by external API services is that a client 
appUcation can be built without including the API service code directly in the client 
application. In particular, such a scheme provides a way for appUcations to declare their 
usage of a particular API service, but defer binding to that API until the application is 

20 actually loaded for execution. This allows application code to be separated from the API 
service code and allows for modularity in the construction of the application run-time 
environment. Extemal API services are said to be "imported" into cUent applications and 
have "load-time binding" to applications. Accordingly, an application declares its intent 
to use imported API services and in response, the compiler can implicitly generate a 

25 "stub" entry in the applications import address table (lAT). The lAT containing import 
stubs can be generated by the compiler. These lAT stubs identify the name of the import 
API and the extemal service or DLL that corresponds with the API. When the 
application is loaded or otherwise made ready for execution, load-time binding will be 
performed and the lAT stubs will be updated to reference the correct API services. 

30 Fig. 1 illustrates a conventional system 100 for linking an application 1 10 and an 

API service provider 120. Application 110 comprises a code section 112 and an lAT 
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1 14. In the code section 1 12, there is a call to import a procedure, here Foo. lAT 1 14 
contains a pointer to the address of the Foo procedure in the API service provider 120. 
Conventional user-mode application shimming techniques are based on manipulating the 
lAT table entries to effect the insertion of functionality. This can be accompUshed by 
5 changing the imported API's entry in the application's lAT to point to shim code rather 
than the original API service code. 

Fig. 2 illustrates a conventional user-mode utilization of a shim 130 between the 
application 1 10 and the API service provider 120. The shim 130 can be written to 
provide a 'Value added" benefit to the API service or it can completely replace the API 

10 service functionality and never call the original API service provider 120. User-mode 

applications run in a process which is essentially owned by the application. Accordingly, 
there is only one client, the application, in the process. This is not true for a system 
process where kemel-mode drivers execute. In a system process, API service providers, 
such as an operating system kernel, are called by a multitude of different and 

1 5 substantially imique drivers. 

Turning briefly to Fig. 3, an exemplary system driver interaction is illustrated. 
Driver X 310 has code 312 which utiUzes lAT 314 to import or link to Foo Procedure 
332 operating system kernel 330. Driver Y 320 has code 322 that employs LAT 324 to 
import or link to VerifierFoo Procedure 334 in system kernel 330, which then calls Foo 

20 Procedure 332 also in the kemel 330. Both drivers were written to invoke Foo Procedure 
or API 332, but Driver X's linkage is different firom that of Driver Y's linkage. Driver Y 
has had its Foo import shimmed by a built in shim, namely VerifierFoo, while Driver X is 
directly linked to the original Foo API in the kemel. 

One important goal of shim developers is reusability. Thus, a good shim 

25 framework should support reuse of shims when possible. If a shim, which provides some 
extended service or fix is created then it is desirable that that shim be applied to all 
applications expressing the problem, for instance, that the shim was designed to correct. 
For example, if Shim X fixes problem X and applications A, B, and C have problem X, 
then it would be desirable to have Shim X be able to fix applications A, B, and C without 

30 any changes to Shim X. However, providing such a common shim has not been possible 
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up to this point, due in part by the fact that different drivers often have different linkage 
configurations, such as Driver X and Driver Y supra. Moreover, conventional user-mode 
shims and shimming systems can retain only one linkage configuration, namely the most 
recent, while other linkage configurations associated with previously shimmed drivers is 
5 lost. Further complicating the problem is the fact that existing infi-astructures for 

imported APIs or services do not readily provide any contextual information with respect 
to which driver is utilizing the API or service. 

Accordingly, there is a need in the art for a shim system and method that can 
determine and maintain a plurality of linkage configurations, context, unique to each 
1 0 application or driver to be shimmed. 

SUMMARY 

The following presents a simplified summary of the invention in order to provide 
a basic understanding of some aspects of the invention. This summary is not an extensive 

1 5 overview of the invention. It is not intended to identify key/critical elements of the 

invention or to delineate the scope of the invention. Its sole purpose is to present some 
concepts of the invention in a simplified form as a prelude to the more detailed 
description that is presented later. 

Disclosed herein is a system and method for establishing and maintaining driver 

20 unique contextual information so that common shims can be utilized to provide some 
service or fix a particular problem associated with a plurality of drivers or other similar 
appUcations. Unique context formation is injected into a shimming system via an 
intermediate context component residing between the driver and a shim component. The 
context component comprises a hook component and a thunk component. The hook 

25 component stores context information regarding a kemel procedure referenced by a 

driver and redirects the driver to the context component. The thunk component links the 
context component to the shim component and provides the shim component with driver 
unique context inforaiation. The shim can then perform its function and subsequently 
link or jump to the kemel procedure or service originally referenced by driver. 
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According to another aspect of the subject invention, a shimming system is 
disclosed herein that implements and supports driver unique context information. More 
particularly, the system comprises a shim engine component that receives a notification 
signal indicating when a driver is loaded. Upon receipt of the signal the shim engine can 
query a shim database to determine if any shim components or shim packages are 
associated with the loaded driver. Thereafter, the shim engine can load any associated 
shim components and generate or load a context component associated with the loaded 
driver. Additionally, the shimming system disclosed herein can include a diagnostic 
component that monitors a system and, upon a system crash or a detected instability or 
ineflFiciency, queries the shim database to determine if a shim component is available that 
if applied would fix or compensate for the problem causing the crash, instability or 
inefficiency. Further yet, the shimming system according to an aspect of the subject 
invention can employ an interface component to facilitate development, deployment, and 
management of shim components and packages by users or developers. 

To the accomplishment of the foregoing and related ends, certain illustrative 
aspects of the invention are described herein in coimection with the following description 
and the annexed drawings. These aspects are indicative of various ways in which the 
invention may be practiced, all of which are intended to be covered by the present 
invention. Other advantages and novel features of the invention may become apparent 
from the following detailed description of the invention when considered in conjunction 
with the drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The foregoing and other aspects of the invention will become apparent fi-om the 

following detailed description and the appended drawings described in brief hereinafter. 
Fig. 1 is a block diagram of a system for linking an application to an application 

service provider. 

Fig. 2 is a block diagram illustrating a conventional shimming system. 

Fig. 3 is a block diagram depicting a system for interacting with a system kemel. 
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Fig. 4 is a block diagram illustrating a kernel-mode driver shimming system is 
illustrated in accordance with an aspect of the present invention. 

Fig. 5 is a block diagram of a driver component in accordance with an aspect of 
the subject invention. 

5 Fig. 6 is a block diagram of a context component in accordance with an aspect of 

the present invention. 

Fig. 7 is a block diagram illustrating an exemplary utilization of context 
components in accordance with an aspect of the subject invention. 

Fig. 8 is a block diagram of depicting a system for kemel-mode driver shimming 
10 in accordance with an aspect of the present invention. 

Fig. 9 is a flow chart diagram illustrating a method of shimming kemel-mode 
drivers in accordance with an aspect of the subject invention. 

Fig. 10 is a flow chart diagram depicting a method of shimming kemel-mode 
drivers in accordance with an aspect of the subject invention. 
15 Fig. 1 1 is a flow chart diagram illustrating a methodology for shimming kemel- 

mode drivers in accordance with an aspect of the present invention. 

Fig. 12 is a schematic block diagram illustrating a suitable operating environment 
in accordance with an aspect of the present invention. 

20 

DETAILED DESCRIPTION 
The present invention is now described with reference to the annexed drawings, 
wherein like numerals refer to like elements throughout. It should be xmderstood, 
however, that the drawings and detailed description thereto are not intended to limit the 
25 invention to the particular form disclosed. Rather, the intention is to cover all 

modifications, equivalents, and alternatives falling within the spirit and scope of the 
present invention. 

As used in this application, the terms "component" and "system" are intended to 
refer to a computer-related entity, either hardware, a combination of hardware and 
30 software, software, or software in execution. For example, a component may be, but is 
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not limited to being, a process running on a processor, a processor, an object, an 
executable, a thread of execution, a program, and/or a computer. By way of illustration, 
both an application running on a server and the server can be a component. One or more 
components may reside within a process and/or thread of execution and a component 
5 may be localized on one computer and/or distributed between two or more computers. 

Furthermore, the present invention may be implemented as a method, apparatus, 
or article of manufacture using standard programming and/or engineering techniques to 
produce software, firmware, hardware, or any combination thereof. The term "article of 
manufacture" (or alternatively, "computer program product") as used herein is intended to 
10 encompass a computer program accessible from any computer-readable device, carrier, or 
media. Of course, those skilled in the art will recognize many modifications may be 
made to this configuration without departing from the scope or spirit of the subject 
invention. 

Turning to Fig. 4, a shimming system 400 is illustrated in accordance with an 

15 aspect of the present invention. System 400 comprises driver component 410, kernel 

component 420, procedures 422 (Procedurei, Procedure2 through ProcedureN, where N is 
greater than one), context component 440 and shim component 430. Driver component 
410 (also referred to herein as simply driver) can be used to perform almost any function 
on a computer however driver components are typically employed to provide an interface 

20 to a particular hardware device or piece of software. Driver component 410 can 

encapsulate special instructions and information associated with a particular device or 
piece of software and provide users (e.g., hardware, software) access to a set of generic 
instructions. Devices or software then utilized the generic commands to communicate 
with a device or software component. The driver component 410 can translate received 

25 generic instructions to the specialized instructions utilized by the device or software 

component. A driver component(s) can be provided by an operating system, by software 
applications, or via software associated with a particular device (e.g., disk drive, printer, 
scanner, keyboard, mouse, speakers. . .). A driver component 410 can be implemented in 
computer systems as dynamically linked library (DLL) files. DLL files are small files 

30 that are utilized by a larger program or device to perform a specific function. For 
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instance, a driver component or DLL file can provide support for a particular device such 
as a printer. The driver component or DLL file can then be utilized by a larger program 
like a word processing program to facilitate printing a document utilizing a particular 
printer associated with the driver component. 
5 Turning briefly to Fig. 5, a driver component 41 0 is illustrated in further detail in 

accordance with an aspect of the subject invention. Driver component 410 comprises 
driver code 412 and import address table 414. Driver code 412 corresponds to software 
specified procedures and functions that driver component 410 utilizes to implement 
driver functionality. Driver component 410 can enhance its utility while minimizing its 

10 overall size by using extemal services or procedures 422 (Fig. 4) provided by the kemel 
component. Driver component 410 accesses extemal procedures 422 by "importing" 
them using an import address table 414. When a driver component 410 is loaded or 
executed the procedures 422 listed in the import table can be boimd to the drivers so that 
the driver can utilized the functions and procedures provided therein. This binding is 

15 referred to herein as driver linkage or import linkage. 

It should be noted that while this detailed description focuses almost exclusively 
on drivers and driver components, the scope of the invention is not so limited. The scope 
of the present invention covers any applications or components, drivers or otherwise that 
are capable of being shimmed. While this description focuses on drivers and driver 

20 components, it is not meant to exclude of all other software applications capable of being 
shimmed, but rather to facilitate a clear and understandable description of the invention 
devoid of confusing terms (e.g., client/application/component/driver). 

Returning to Fig. 4, kemel component 420 is the nucleus or core of a computer 
operating system. An operating system is generally responsible for processing data and 

25 managing input and output. Kemel component 420, as part of the operating system, is 
loaded first and remains in main memory. In addition to being responsible for process 
management, file management, and memory management, inter alia, the kemel 
component 420 provides the essential services or procedures 422 required by applications 
and drivers. Procedures 422 can correspond to but are not limited to I/O scheduling, 

30 buffering, spooling, and error handling. Furthermore, it should be noted that the term 
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kernel-mode service or kernel-mode procedure as used herein is intended to cover any 
service, procedure, driver, application or other component located in the kernel address 
space. 

Shim component 430 provides additional functionality between driver component 
5 410 and kernel services or procedures 422. According to one aspect of the subject 

invention such functionality can correspond to a fix for a faulty driver; however shim 
component 430 can also be utilized as a diagnostic shim to assist in root cause analysis. 
Faulty drivers can be the cause of many system crashes and other problems that 
contribute to a negative computer experience delays, lockups. . .) which are usually 

10 incorrectly attributed to an operating system. A shim component 420 provides a 
mechanism for fixing a driver's behavior by compensating for the drivers fault. 
Accordingly, the shim component 430 resides between one or more driver components 
410 and a kernel component with desirable procedures 422. However, unlike 
conventional shimming systems the present invention also employs a context component 

15 440. 

Context component 440 is an intermediate component between a driver system 
call and a common shim component 430. Context component 440 provides a mechanism 
to establish and maintain unique per-driver linkage information. Conventional shinmiing 
systems do not establish a context for each driver calling a shim component, rather they 

20 retain only one linkage configuration embedded in the shim itself, specifically the linking 
configuration of the last driver shimmed. Therefore, all shim linkage configuration data 
related to a previously shimmed driver is lost. Turning to Fig, 6, a context component 
440, in accordance with an aspect of the subject invention, is illustrated in further detail 
including hook component 442 and thunk component 444. Hook component 442 can be 

25 constructed during the loading of the subject driver. Hook component 442 retrieves 

contextual information from a driver to be shinmied (e.g., using a shim engine component 
described infra) and makes such information available to thunk component 444. In 
particular, hook component 442 can retrieve the address of the kernel procedure or 
service sought to be utilized by a driver firom the driver's import address table (lAT). 

30 Furthermore, hook component 442 can determine the address of the shim to be utilized. 
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This context data can then be stored in a data structure for later access by the thunk 
component 442 and the shim component 430. Thunk component 444 utiUzes 
information retrieved by hook component 442 to change a driver's import address table 
to point to or reference the location of the shim rather than the originally specified service 
5 or procedure. Furthermore, thunk component 444 provides the shim component 430 with 
access to the context information related to the driver calling the shim component 430. 
The context information can be provided to the shim component 430 by passing such 
information or the location of the information as a procedure parameter or storing the 
data in a particular location known by the shim component 430. The shim component 
10 430 can then utilize this information to retrieve the calling driver's originally referenced 
kemel procedure. Subsequently, the shim component 430 can chain forward to the 
originally reference procedure or service after providing additional functionality (e.g., 
driver fix). 

Tuming to Fig. 7, a block diagram of an exemplary system 700 in accordance 

15 with an aspect of the invention is illustrated. System 700 depicts the use of context 

components amongst two different driver components. Driver X 710 and driver Y 720 
contain respective driver code 712 and 722 as well as import address tables 714 and 724. 
Furthermore, each driver is associated with a context component 730 and 740. A 
common shim component 750 is utilized to provide additional fimctionality between the 

20 drivers and kemel component procedures Foo 762 and VerifierFoo 764. Driver X 710 
utilizes Foo procedure 762 in its code section 710. Accordingly, there is a pointer in 
driver X's import address table 714 pointing to the memory location containing kemel 
procedure 762. Here, however, a shim component 750 has been employed to provide 
additional fimctionality, for example compensating for a problem with driver X 710. In 

25 accordance with an aspect of the subject invention a context component 730 is also 
employed to provide driver specific context information to the shim component 750. 
Context component 730 includes a hook component 732 and a thunk component 734. 
Hook component 732 changes the pointer in import address table 714 originally 
referencing Foo to point or link driver X's import of the Foo procedure to context 

30 component 730. Additionally, context component 730 receives the memory address of 
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the shim component 750 and stores, inter alia, a pointer to the shim component 750 and a 
pointer to the originally referenced kemel procedure Foo 762 in a data structure, here 
Hook struct. Thus, hook struct contains the driver context information. Thunk 
component 734 utilizes this information to jump to the shim component 750 and provide 
5 shim component 750 with context data. After the jxunp is complete, shim component 750 
executes its function and then utilizes the context data to link and ultimately execute the 
original procedure call Foo 762. 

Driver Y 720 goes through a similar process with the common shim component 
750. In this case, however, driver Y 720 utilizes its own context component 740 and a 

10 different procedure call. Driver Y 720 ultimately seeks to call Foo procedure 762, but as 
shown here after calling VerifierFoo procedure 764. The hook component 742 of the 
driver context component 740 determines and saves information related to the procedure 
called by the shim component 750. Thimk component 744 the links the driver to the 
shim component 750 by changing is the reference address in driver Y's import address 

15 table 724. Thereafter, when driver Y 720 calls the Foo procedure in its code section 722 
control is transferred to the context component 740. Context component then stores the 
stores a pointer to the context information in a register or by altemative means transfers 
the location of the context information or the context information itself to shim 
component 750. Shim component 750 then executes its fimctionality and then using the 

20 context information jumps to the verifier procedure 764, which executes and jumps to the 
Foo procedure 762. It should be noted that by retrieving and maintaining context data for 
each driver, the subject invention ensures that context data for previously shimmed 
drivers is not lost upon the utilization or calling of the shim by another driver. 
Conventional shimming practices would have lost information regarding the context of 

25 the driver X 710 upon execution of driver Y 720. In this case, if driver X 710 was called 
again after driver Y 720, a conventional shim would not know which procedure driver X 
710 originally referenced as context data would not have been retained and the reference 
in the drivers import address table would have been changed to reference the shim 
component 750. The present invention eluninates this problem by storing unique context 

30 information for each driver component. 
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Fig. 8 depicts a system 800 for utilizing shims in accordance with an aspect of the 
subject invention. System 800 comprises driver loader component 810, shim engine 
component 820, shim database 830, diagnostic component 840, and interface component 
850. Driver loader component 810 receives a signal from an entity (e.g., person, 
5 application, device, plug-and-play component. . .) to load a driver. Driver loader 

component 810 establishes driver initial linkage and loads a target driver into memory for 
execution. The loader component 810 can resolve any imresolved dynamic references 
the driver may have for external APIs or processes and when all references are resolved 
generate a notification signal. The notification signal provides, among other things, the 

10 identity of the driver being loaded to the shim engine component 820. Such notification 
signaling allows other services to receive control during the driver load procedure just 
prior to the driver being called. The shim engine component receives the notification 
signal and utilizes the information contained therein to query the shim database 830 to 
determine if the target driver is to be shimmed. The shim database 830 acts as a central 

15 repository for the data concerning which drivers need to be shimmed and which shim 
components are to be applied to particular drivers. If the shim engine component 820 
determines, utilizing at least the shim database 830, that a driver should be shimmed, the 
shim engine component identifies the set of shims or shim package to be applied, loads 
them (if not already loaded), and allows the shims to initialize a unique context. 

20 Subsequently, the shim engine component 820 can redirect the target driver API imports 
to one or more shim components. 

System 800 can also include a diagnostic component 840 that analyzes a 
computer system and initiates corrective action. According to one aspect of the subject 
invention the diagnostic component 840 assists in root cause analysis of a system crash. 

25 The diagnostic component can therefore employ a variety of methods of analyzing 

system dump information and/or a program trace (e.g., utilizing expert systems, neural 
networks. . .) to determine the cause of the crash. However, diagnostic component 840 
need not wait for a system crash. The diagnostic component 840 can also be proactive 
and engage in system analysis to detect system instabilities and/or inefficiencies. Upon 

30 determining the cause of a crash or detecting system instabilities and/or inefficiencies, 
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corrective action can be initiated by the diagnostic component 840. Such corrective 
action can include providing notification to a user or operator via interface 850. 
Corrective action can also comprise searching the shim database 830 to determine 
whether a shim component already exists that if appUed can fix the detected problem, 
5 instability or inefficiency. Such a determination can be made intelligently using 

Bayesian networks, nexiral networks, decision trees, support vector machines, linear and 
non-linear regression and/or other learning models. According to an aspect of the 
invention, the diagnostic component can engage in a probabilistic analysis based on the 
cost of making and incorrect diagnosis and/or selecting the wrong shim weighed against 

10 the benefit of correction. Confidence levels may be employed and specified by a 
developer or user to control actions of the diagnostic component. 

Literface component 850 enables a user to interact with the shim database 830. 
According to one aspect of the invention, the interface component 850 is a graphical user 
interface (GUI) that facilitates creation of a shim component or shim package for a driver 

15 and storage of the shim component or shim package to shim database 830. For example, 
the interface component 850 can be a wizard that presents a user with a series of steps in 
graphical windows that aids in the generation of a shim component to remedy a detected 
problem, instability, or inefficiency. The interface component 850 can also provide a 
developer or user a means for developing and deploying a diagnostic shim component 

20 that can assist in imderstanding an operation sequence to determine or converge upon a 
problem. 

In view of the exemplary systems described supra, a methodology that may be 
implemented in accordance with the present invention will be better appreciated with 
reference to the flow charts of Figs. 9-11. While for purposes of simplicity of 

25 explanation, the methodology is shown and described as a series of blocks, it is to be 
understood and appreciated that the present invention is not limited by the order of the 
blocks, as some blocks may, in accordance with the present invention, occur in different 
orders and/or concurrently with other blocks fi-om what is depicted and described herein. 
Moreover, not all illustrated blocks may be required to implement the methodology in 

30 accordance with the present invention. 
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Additionally, it should be further appreciated that the methodologies disclosed 
hereinafter and throughout this specification are capable of being stored on an article of 
manufacture to facilitate transporting and transferring such methodologies to computers. 
The term article of manufacture, as used, is intended to encompass a computer program 
5 accessible from any computer-readable device, carrier, or media. 

Turning to Fig. 9, a methodology 900 for shimming kernel mode drivers is 
depicted in accordance with an aspect of the present invention. At 910, a shim 
component common to several drivers is generated. A common shim component 
provides an efficient mechanism to add functionality to one or more drivers so as to 

10 compensate for a fault associated with the one or more drivers, for example. A shim 
component can be generated using a program editor and/or a graphical user interface. 
Alternatively, a shim component can be generated using a wizard that guides a user or 
developer through a series of steps associated with generating a shim component utilizing 
a myriad of windows and graphical interface components such as buttons, scroll bars, text 

15 boxes and the like. At 920, driver unique context data is generated for each driver to be 
shimmed. Subsequently, the driver unique context is provided to the common shim at 
930. The unique context data allows the common shim component to identify the driver 
that is utilizing the shim component. This enables the shim component to add additional 
functionality and then chain forward to the kemel-mode service or procedure utilized by 

20 the driver and therefore leaves a driver's chain of execution intact. 

Fig. 10 is a flow chart diagram illustrating a methodology 1000 for shimming 
kemel mode drivers in accordance with an aspect of the subject invention. At 1010, a 
shim component common to a plurality of drivers is generated. As mentioned supra^ the 
shim component provides an efficient mechanism to add functionality to a driver for 

25 instance to compensate for some fault referencing restricted memory. . .). However, 
it should also be noted that a shim component can be utilized as a tool to determine and 
pinpoint system problems. The shim component can be generated using one of several 
methods, components, and devices, for example using a GUI or a wizard. At 1020, a 
driver's imported API or kemel-mode service is retrieved from the drivers import address 

30 table. Subsequently, the drivers API service reference in its import address table is 
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replaced with a pointer to the shim component at 1030. The replaced API or kernel 
kernel-mode service is then provided to the shim at 1040. This context information can 
be provided to the shim component by employing it as a parameter in a function or 
procedure calling the shim, by loading it to a particular memory location, and the like. 
5 Accordingly, a driver associated with a common shim component becomes linked to the 
shim component, which is then able to chain forward to the API or kemel-mode service 
after the shim component executes its additional added functionality. 

Fig. 1 1 depicts a method 1 100 of modifying kernel mode drivers in accordance 
with an aspect of the subject invention. At 1 1 10, a signal is received indicating that a 

10 driver has been loaded. In accordance with one aspect of the invention, the signal can be 
generated by a driver loader component after resolving any unresolved dynamic 
references the driver may have for extemal APIs. Such notification allows other services 
to receive control just prior to the driver's driver entry being called. At 1 120, a query is 
performed on the shim database to determine if a driver is one that is to be shimmed. A 

15 determination is then made at 1 130 as to whether the driver is to be shimmed based on 

the existence or nonexistence of shim components associated with the driver. If there are 
no shims associated with the driver then the procedure is terminated. If, however, there is 
one or more shims associated with the driver then the process proceeds to 1 140 where a 
unique driver context is initialized and loaded. Subsequently, the driver is redirected to 

20 the shim component rather than a driver import entry such as a kernel-mode service or 
procedure at 1 1 50. Such redirection can be accomplished by replacing an entry in the 
driver's import address table with a pointer to the shim component. Thereafter, the shim 
component can but is not required to utilize the unique driver context to chain forward to 
the replaced driver import entry. 

25 In order to provide a context for the various aspects of the invention. Fig. 12 as 

well as the following discussion are intended to provide a brief, general description of a 
suitable computing environment in which the various aspects of the present invention 
may be implemented. While the invention has been described above in the general 
context of computer-executable instructions of a computer program that runs on a 

30 computer and/or computers, those skilled in the art will recognize that the invention also 
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may be implemented in combination with other program modules. Generally, program 
modules include routines, programs, components, data structures, etc. that perform 
particular tasks and/or implement particular abstract data types. Moreover, those skilled 
in the art will appreciate that the inventive methods may be practiced with other computer 
5 system configurations, including single-processor or multiprocessor computer systems, 

mini-computing devices, mainframe computers, as well as personal computers, hand-held 
computing devices, microprocessor-based or programmable consumer electronics, and 
the like. The illustrated aspects of the invention may also be practiced in distributed 
computing environments where task are performed by remote processing devices that are 
10 linked through a conraiunications network. However, some, if not all aspects of the 
invention can be practiced on stand-alone computers. In a distributed computing 
environment, program modules may be located in both local and remote memory storage 
devices. 

With reference to Fig. 12, an exemplary environment 1210 for implementing 
15 various aspects of the invention includes a computer 1212. The computer 1212 includes 
a processing unit 1214, a system memory 1216, and a system bus 1218. The system bus 
1218 couples system components including, but not limited to, the system memory 1216 
to the processing unit 1214. The processing unit 1214 can be any of various available 
processors. Dual microprocessors and other multiprocessor architectures also can be 
20 employed as the processing unit 1214. 

The system bus 1218 can be any of several types of bus structure(s) including the 
memory bus or memory controller, a peripheral bus or external bus, and/or a local bus 
using any variety of available bus architectures including, but not limited to, 1 1-bit bus. 
Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended 

25 ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral 
Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port 
(AGP), Personal Computer Memory Card International Association bus (PCMCIA), and 
Small Computer Systems Interface (SCSI). 

The system memory 1216 includes volatile memory 1220 and nonvolatile 

30 memory 1222. The basic input/output system (BIOS), containing the basic routines to 
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transfer information between elements within the computer 1212, such as during start-up, 
is stored in nonvolatile memory 1222. By way of illustration, and not limitation, 
nonvolatile memory 1222 can include read only memory (ROM), programmable ROM 
(PROM), electrically programmable ROM (EPROM), electrically erasable ROM 
5 (EEPROM), or flash memory. Volatile memory 1220 includes random access memory 
(RAM), which acts as external cache memory. By way of illustration and not Umitation, 
RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM 
(DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), 
enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus 
10 RAM (DRRAM). 

Computer 1212 also includes removable/non-removable, volatile/non- volatile 
computer storage media. Fig. 12 illustrates, for example disk storage 1224. Disk storage 
4124 includes, but is not limited to, devices like a magnetic disk drive, floppy disk drive, 
tape drive, Jaz drive, Zip drive, LS-lOO drive, flash memory card, or memory stick. In 
1 5 addition, disk storage 1224 can include storage media separately or in combination with 
other storage media including, but not limited to, an optical disk drive such as a compact 
disk ROM device (CD-ROM), CD recordable drive (CD-R Drive), CD rewritable drive 
(CD-RW Drive) or a digital versatile disk ROM drive (DVD-ROM). To facilitate 
connection of the disk storage devices 1224 to the system bus 1218, a removable or non- 
20 removable interface is typically used such as interface 1226. 

It is to be appreciated that Fig 12 describes software that acts as an intermediary 
between users and the basic computer resources described in suitable operating 
environment 1210. Such software includes an operating system 1228. Operating system 
1228, which can be stored on disk storage 1224, acts to control and allocate resources of 
25 the computer system 1212. System appUcations 1230 take advantage of the management 
of resources by operating system 1228 through program modules 1232 and program data 
1234 stored either in system memory 1216 or on disk storage 1224. It is to be 
appreciated that the present invention can be implemented with various operating systems 
or combinations of operating systems. 
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A user enters commands or information into the computer 1212 through input 
device(s) 1236. Input devices 1236 include, but are not limited to, a pointing device such 
as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, 
satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, 
5 and the like. These and other input devices connect to the processing unit 1214 through 
the system bus 1218 via interface port(s) 1238. Interface port(s) 1238 include, for 
example, a serial port, a parallel port, a game port, and a universal serial bus (USB). 
Output device(s) 1240 use some of the same type of ports as input device(s) 1236. Thus, 
for example, a USB port may be used to provide input to computer 1212, and to output 

10 information from computer 1212 to an output device 1240. Output adapter 1242 is 

provided to illustrate that there are some output devices 1240 like monitors, speakers, and 
printers, among other output devices 1240, that require special adapters. The output 
adapters 1242 include, by way of illustration and not limitation, video and sound cards 
that provide a means of connection between the output device 1240 and the system bus 

15 1218. It should be noted that other devices and/or systems of devices provide both input 
and output capabilities such as remote computer(s) 1244. 

Computer 1212 can operate in a networked environment using logical connections 
to one or more remote computers, such as remote computer(s) 1244. The remote 
computer(s) 1244 can be a personal computer, a server, a router, a network PC, a 

20 workstation, a microprocessor based appUance, a peer device or other conraion network 
node and the like, and typically includes many or all of the elements described relative to 
computer 1212. For purposes of brevity, only a memory storage device 1246 is 
illustrated with remote computer(s) 1244. Remote computer(s) 1244 is logically 
connected to computer 1212 through a network interface 1248 and then physically 

25 connected via communication connection 1250. Network interface 1248 encompasses 
communication networks such as local-area networks (LAN) and wide-area networks 
(WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper 
Distributed Data Interface (CDDI), Ethemet/IEEE 1 102.3, Token Ring/IEEE 1 102.5 and 
the like. WAN technologies include, but are not limited to, point-to-point links, circuit 
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switching networks like Integrated Services Digital Networks (ISDN) and variations 
thereon, packet switching networks, and Digital Subscriber Lines (DSL). 

Communication connection(s) 1250 refers to the hardware/software employed to 
connect the network interface 1248 to the bus 1218. While communication connection 
1250 is shown for illustrative clarity inside computer 1212, it can also be external to 
computer 1212. The hardware/software necessary for connection to the network interface 
1248 includes, for exemplary purposes only, intemal and extemal technologies such as, 
modems including regular telephone grade modems, cable modems and DSL modems, 
ISDN adapters, and Ethemet cards. 

What has been described above includes examples of the present invention. It is, 
of course, not possible to describe every conceivable combination of components or 
methodologies for purposes of describing the present invention, but one of ordinary skill 
in the art may recognize that many further combinations and permutations of the present 
invention are possible. Accordingly, the present invention is intended to embrace all 
such alterations, modifications and variations that fall within the spirit and scope of the 
appended claims. Furthermore, to the extent that the term "includes" is used in either the 
detailed description or the claims, such term is intended to be inclusive in a manner 
similar to the term "comprising" as "comprising" is interpreted when employed as a 
transitional word in a claim. 
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